home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19971216-19980424 / 000134_news@newsmaster….columbia.edu _Wed Jan 28 21:01:50 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA09331
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 28 Jan 1998 21:01:50 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id VAA00199
  7.     for kermit.misc@watsun; Wed, 28 Jan 1998 21:01:49 -0500 (EST)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Expect and Kermit (was: Re: frequent timeouts!)
  12. Date: 29 Jan 1998 02:01:49 GMT
  13. Organization: Columbia University
  14. Lines: 65
  15. Message-ID: <6aonud$42r$1@apakabar.cc.columbia.edu>
  16. References: <6ao7uh$9qf$1@cronkite.ocis.temple.edu> <6ao98e$p4h$1@apakabar.cc.columbia.edu> <gerlachEnIuIF.K4L@netcom.com>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:8316
  19.  
  20. In article <gerlachEnIuIF.K4L@netcom.com>,
  21. Matthew H. Gerlach <gerlach@netcom.com> wrote:
  22. : The kermit scripting language is a greate thing, most notably the fact
  23. : that kermit scripts will run on many platforms.  That being said I find
  24. : it very beneficial to control C-Kermit from Expect, and I work for a company
  25. : that does a lot of it.  The main benefit is that one might need to write
  26. : a script that controls many serial connections in conjuction with
  27. : many connections to regular UNIX programs.  This appears to be easier with
  28. : Expect.
  29. :
  30. Some concrete examples might be instructive.
  31.  
  32. : Furthermore, Tk/Expect allows one to easily put a "pretty face" 
  33. : gui on said script.
  34. : 
  35. One ought to be able to do that anyway.  Code the user interface in Tk/Expect
  36. or whatever, and the real stuff in the Kermit script.  Keeps the bosses happy
  37. by looking pretty, and keeps the rest of us happy by working well :-)
  38.  
  39. : In conclusion there are problems best solved by kermit scripts and problems
  40. : best solved using Expect and there are even more problems best suited to 
  41. : Perl, which I prefer.  Use the best tool to solve the problem.
  42. : 
  43. Agreed, provided it works.  If Kermit doesn't work with expect (I'm not
  44. saying it doesn't), then the best tool is Kermit without expect.  Given the
  45. amount of resources we have, there is a limit to the number of combinations
  46. we can support.  But of course, that's where this newsgroup comes in handy.
  47.  
  48. Meanwhile, I think this is a useful dialog.  If my understanding of the 
  49. Expect approach is correct, it is basically a screen-scraper, looking for
  50. the Kermit prompt, feeding commands to it, parsing the results, and so on
  51. in a loop of some kind until the desired result is achieved.  But Kermit's
  52. language includes a lot of features that don't fit this model, such as
  53. FOR and WHILE loops, SWITCH statements, IF-ELSE constructions, even GOTOs.
  54. I suppose these might be simulated at a "higher level", but isn't that
  55. pushing the model a bit?  Also, note that every Kermit command returns a
  56. status that can be tested by IF SUCCESS (or IF FAILURE); how do you do that
  57. with Expect?
  58.  
  59. For actual communications, Kermit's INPUT and OUTPUT (and IF, etc) commands
  60. perform selected actions based on what the other computer sends.  The MINPUT
  61. command is especially handy, allowing us to scan for several strings at
  62. once, for example:
  63.  
  64.   set carrier-watch off
  65.   while 1 {
  66.       output ATDT7654321\13
  67.       minput 60 CONNECT {NO ANSWER} {NO DIALTONE} {NO CARRIER} BUSY
  68.       switch \v(minput) {
  69.     :0, end 1 Timed out
  70.     :1, echo Call complete, break
  71.     :2, end 1 No answer - try again later.
  72.     :3, end 1 No dialtone - check the phone.
  73.         :4, end 1 Connection failed.
  74.         :5, echo Redialing..., continue
  75.         :default, stop 1 impossible error    
  76.       }
  77.   }
  78.  
  79. (This does approximately what the built-in DIAL command does.)  You can put
  80. this loop in another loop that calls a list of numbers in succession, in a
  81. table-driven way, and so on.  How would one do this by having Expect feed
  82. commands to the C-Kermit prompt?
  83.  
  84. - Frank